I would like to have the option to have SD stop navigating automatically after landing. I sometimes forget to do this manually and end up with a "flight track" that follows me as I drive away from the airport.

I have to admit that I have a lot of "flights" between the airfield and home as well...
Thankfully, they are always divided from the real flights, so deleting hasn't been an issue so far.

I'll second the notion of having an auto stop as well. 
Not sure how it would be implemented from an algorithm perspective though.

I don't like the idea of SD stopping to log automatically after a flight. I use the "Go Flying" and "Stop Navigating" options to mark engine start and stop times. Therefore I need to be in control when logging starts and stops.

-- Chris.

Chris

That's fine: so why not make auto-stop an option, then we're both happy?

Because the world doesn't need more options. I think it needs to be an explicit user action, myself.

Because the world doesn't need more options. I think it needs to be an explicit user action, myself.

+1....Bit like putting the wheels down ;-)

Why does it need to be a specific user action? Maybe I'm an exception, but I keep forgetting to tell it to stop navigating and it irritates me when I discover later that it has tracked my subsequent road journey as well (and drained my battery because the GPS has been running all the time!).

One of the reasons SD is so successful is that it caters for a very wide range of users and it does so by providing lots of options already, so saying that: "the World doesn't need more options" seems to run counter to that successful philosophy.

Not having this feature wouldn't stop me liking or using SD, but I do think it would be worth including.

The key to creating a successful piece of software is to make it so that a large group of users draws significant benefit from using it. It is common misconception that a program needs to satisfy EVERY user's whims. Even if you could do so by implementing loads of option and making everything user configurable you wouldn't succeed. You need to maintain a careful balance between useful options and options for option's sake. Unless there is a significant number of people who think they would benefit from such an option, Tim does right by not incorporating it into the software.

So far, I believe Tim has done an admirable job steering a good course by making the software as powerful and adaptable as necessary while still keeping it as simple as possible. There are a number of examples where programs drown in their options and ultimatly succeed in making everyone unhappy.

-- Chris.

Our philosophy has always been to shy away from options. A personal philosophy of mine (sweeping and doesn't apply everywhere of course) is that if you have to make an option for it, you haven't implemented it right in the first place.

There is a particular competitor of ours which I won't name, which has loads of features, and literally hundreds of options for configuring them all. It must be possible to have it do practically anything you want it to do. It is not particularly popular, and is in my view bordering on unusable.

I'm always happy to consider user-suggested features but in this particular example, I am happy with the way SkyDemon already works.